In customer relationship management (CRM) environments, agents (e.g., sales agents, telemarketing agents, customer service and support agents, etc.) tend to interact with multiple clients simultaneously, either to solve their issues or try to sell them products. For example, market research indicates that agents deal with an average of 2.5 client communications simultaneously. Encouraging agents to multitask through multiple communication channels increases the company's reputation and profitability by improving the throughput of problem resolution (thus making for happy clients). Further, having agents multitask through multiple channels increases the company's operations by needing fewer agents to accomplish the workload, possibly in less time and at a lower cost.
In some CRM systems, each business object (e.g., an email, a problem report, etc.) is usually opened in a separate window or tab opened by the business application corresponding to the business object (e.g., an email reader, a tracking application window, etc.). As a more detailed example, an email reader might open a window corresponding to a particular client's emailed problem report. Or, an issue tracking application might open a window corresponding to a particular client issue report.
Such organization exemplifies a well-known usability problem present in legacy user interfaces (UIs), which problem is often exhibited when users are multitasking: That is, too many windows and/or tabs and/or applications are opened for different purposes, and users too easily lose track of which window or tab corresponds to which task. Often users resort to clicking through all the open windows or tabs to find out which one they should work with next.
Some CRM systems organize business objects into two levels, as follows: A top-level business object serves as a root to group second-level objects that belong together. For example, using such legacy CRM systems, agents can choose to group service requests (SRs) based on their respective associated account. In this example, a given account is shown as a top-level tab, and all of the SRs opened for this account are shown as secondary tabs under this top-level tab. In such an organization, the top-level business objects create a context to group the secondary-level objects that belong to them. In a specific case of the Salesforce Service Cloud Console, agents can group service requests (SRs) based on the associated account. Each account is a top-level tab, and all the SRs opened with this account are secondary tabs under this top-level tab. This two-level-tab approach improves the usability in certain cases but cannot help if multiple tasks that an agent is working on are with the same account, that is, where the business objects from different tasks are again mixed in a single context. The aforementioned two-level tab approach is business-object-centered—not task-centered. Indeed, it is a common occurrence that a single account will have multiple tasks to solve concurrently (e.g., to solve different client issues for the same company), and even the aforementioned two-level-tab approach is still deficient since merely associating multiple SRs to the same common account does not aid the agent to manage the separate events and separate responses that emanate from the separate simultaneously-active service requests.
In some other legacy embodiments, and observing a call-center approach, when an agent launches a phone call to a customer or takes a customer's incoming phone call, a Computer-Telephony Integration application or channel is usually added into a user interface (UI) shell with which the agent is working. A real-time customer phone call forms an entry in the UI shell and creates a context to group together all the business objects that are opened in the agent console during the phone call. In some cases such a UI shell has been extended to accept customer live chats as well, where a customer chat request is added to, or creates a context. As a specific example, an agent might want to engage in simultaneously-active events such as a voice phone call while texting/chatting using a text window. Yet, implementing a UI shell approach alone for amalgamating communications remains communication-centric, not task-centric, and improvements such as are disclosed herein are needed.
A client initiates a live chat with an agent. During the chat session, certain web collaboration tools are used, such as screen sharing or remote control of the client's machine. During the session, the agent realizes that chatting about certain complicated issues is slow and inefficient. The agent dials the client's phone number (e.g., possibly using the user interface of a computer-telephony integration application) in expectation that the phone interaction will improve the collaboration during the chat session. Unfortunately, in this scenario, the chat session and the live phone call are presented in two separate contexts in the UI shell, and the agent has to switch back and forth between these two contexts while engaged on solving the client's problem. In this scenario, the contexts are not task-centered, and the aspect of having to operate separate (and possibly very different) user interfaces in order to service a single client hinders the agent's multitasking performance.
These and other scenarios demand new techniques to bring multiple engagement activities or events under one task-centric console so as to federate those activities. The aforementioned legacy technologies do not facilitate task-centered context management. Therefore, there is a need for improved approaches.